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REMARKS 

Applicant thanks the Examiner for the Interview held on December 1 7, 2004 and for 
indicating that the proposed amendment to claim 1 appears to overcome the art of record.. 

Claims 1-2, 4-16, and 18-20 are pending. By this amendment, claims 1, 9, and 15 are 
amended. No new matter is introduced. Support for the amendments may be found at least 
at page 1, lines 22-28, page 3, line 31 to page 4, line 9, and page 6, lines 13-18 of the 
specification. Reconsideration and allowance of all pending claims is respectfully requested 
in view of the preceding amendments and following remarks. 

Entry of the above amendments is proper under 37 C.F.R. § 1.116 because the 
amendments (1) place the claims in better form for appeal if needed; and (2) do not introduce 
any elements requiring further search by the Examiner. 

Claim Rejections Under 35 U.S.C. §102 

Claims 1-2, 4-16, and 18-20 are rejected under 35 U.S.C. §102 (a) over U.S. Patent 
6,604,1 08 to Nitahara (hereafter Nitahara). This rejection is respectfully traversed. 

Nitahara is directed to an information mart system and information mart browser. 
The information mart system collects financial and testing data in the context of drug testing 
by pharmaceutical companies. However, as agreed upon during the Interview, Nitahara does 
not disclose or suggest "maintaining database tables in individual data contexts, wherein the 
database tables contain data from multiple data sources, and wherein data in one data source 
has a same identifier as a duplicate data in another data source ; appending a source identifier 
as a key field to the data before merging the database tables into one larger table in a display 
context so that name spaces of the data are unique within each data context; merging the 
database tables into one larger table in the display context by blending the data from the 
multiple data sources without violating relational database rules ," as recited in amended 
claim 1 (emphasis added). 

The conduits recited in claim 1 provide an abstraction layer to make the data unique 
so that the data can be combined into a single database without violating relational database 
rules. The specification provides in the Background Section at page 1, lines 21-28: 

The relational database model used by many database management 
systems can manage data from a single source. Faced with multiple data 
sources, (for example, multiple connections to the same databases or servers 
via the API, or live connections to databases or servers in conjunction with 
open copies of previously saved data,) a user typically must launch a 
completely separate user interface to manage each data source, because the 
duplicate data from the various sources described above can lead to 
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duplication of database keys used to access and manage the data. This is a 
violation of the relational database model that cannot be allowed. 

(Emphasis added). Further, the present application describes at page 3, line 31 to page 4, line 
9: 

When a data source is open, the data source typically refers to each 
fundamental element, such as a cluster, a node, or a package, by a unique 
identifier. In other words, all key fields for the database may be unique in 
individual data context. However, if data from the individual data context are 
blended together, or if two data sources are open at the same time, the 
identifiers of the saved file may be the same as the identifiers in the live 
connection to the clusters, nodes, and packages. In other words, primary keys 
of database tables, i.e., name spaces, are no longer unique, violating the 
relational database model. 

The method for managing data from multiple data sources using 
conduits involves maintaining database tables for each data source in 
individual data context, and merging the database tables into larger tables in a 
display context. The method ensures key values within the display data 
context are unique by appending a source identifier as a key field to the data 
before combining or updating the database tables in the display context. 

(Emphasis added). When data in one data source has a same identifier as a duplicate data in 
another data source, merging database tables containing these data will lead to violation of 
the relational database rules, as explained above. The method recited in claim 1 solves this 
problem by appending a source identifier as a key field to the data. The method merges the 
database tables into one larger table by blending the data from the multiple data sources 
without violating the relational database rules. Figure 14 (and corresponding text) of 
Nitahara merely shows one table containing five primary frames of equal quadrants to display 
information mart files. Nowhere does Nitahara shows merging database tables and blending 
data (with potential same identifiers) from multiple data sources without violating the 
relational database rules . Therefore, claim 1 is allowable. 

Claims 2 and 4-8 are allowable because they depend from allowable claim 1 and for 
the additional features they recite. 

Regarding claim 9, for at least the same reason as stated above with respect to claim 
1, Nitahara does not disclose or suggest "one or more data contexts . . . wherein data in one 
data source has a same identifier as a duplicate data in another data source ... a conduit that 
append a source identifier as a key field to the data before merging the database tables into 
one larger table in the display context so that name spaces of the data are unique within each 
data context, wherein the data from the multiple data sources are blended and merged into the 
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one larger table without violating relational database rules ," as recited in amended claim 9 
(emphasis added). Since Nitahara does not disclose or suggest all of the elements of 
amended claim 9, claim 9 is allowable. 

Claims 10-14 are allowable because they depend from allowable claim 9 and for the 
additional features they recite. 

Regarding claim 15, for at least the same reason as stated above with respect to claim 
1 , Nitahara does not disclose or suggest "maintaining database tables in individual data 
contexts, wherein the database tables contain data from multiple data sources, and wherein 
data in one data source has a same identifier as a duplicate data in another data source ; 
appending a source identifier as a key field to the data before merging the database tables into 
one larger table in a display context so that name spaces of the data are unique within each 
data context; merging the database tables into one larger table in the display context by 
blending the data from the multiple data sources without violating relational database rules ," 
as recited in amended claim 15 (emphasis added). Since Nitahara does not disclose or 
suggest all of the elements of amended claim 15, claim 15 is allowable. 

Claims 16 and 18-20 are allowable because they depend from allowable claim 15 and 
for the additional features they recite. Withdrawal of rejections of claims 1-2, 4-16, and 18- 
20 is respectfully requested. 

In view of the above remarks, Applicant respectfully submits that the application is in 
condition for allowance. Prompt examination and allowance are respectfully requested. 

Should the Examiner believe that anything further is desired in order to place the 
application in even better condition for allowance, the Examiner is invited to contact 
Applicant's undersigned representative at the telephone number listed below. 



Respectfully submitted, 



Date: February 2, 2005 




Kelly T. Lee 
Registration No. 47,743 
Andrews & Kurth LLP 

1701 Pennsylvania Ave, N.W. 
Suite 300 

Washington, DC 20006 
Tel. (202) 662-2736 
Fax (202) 662-2739 
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